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Abstract 

Instant Messaging has attracted a lot of attention by users for both private and business 
communication and has especially gained popularity as low-cost short message replacement on 
mobile devices. However, most popular mobile messaging apps do not provide end-to-end security. 

Press releases about mass surveillance performed by intelligence services such as NSA and GCHQ 
lead many people looking for means that allow them to preserve the security and privacy of 
their communication on the Internet. Additionally fueled by Facebook’s acquisition of the hugely 
popular messaging app WhatsApp, alternatives that claim to provide secure communication 
experienced a significant increase of new users. 

A messaging app that has attracted a lot of attention lately is TextSecure, an app that 
claims to provide secure instant messaging and has a large number of installations via Google’s 
Play Store. It’s protocol is part of Android’s most popular aftermarket firmware CyanogenMod. 

In this paper, we present the first complete description of TextSecure’s complex cryptographic 
protocol and are the first to provide a thorough security analysis of TextSecure. Among other 
findings, we present an Unknown Key-Share Attack on the protocol, along with a mitigation 
strategy, which has been acknowledged by TextSecure’s developers. Furthermore, we formally 
prove that — if our mitigation is applied — TextSecure’s push messaging can indeed achieve the 
goals of authenticity and confidentiality. 

I. Introduction 

Since more than a decade, Instant Messaging (IM) has attracted a lot of attention by users 
for both private and business communication. IM has several advantages over classical e-mail 
communication, especially due to the chat-like user interfaces provided by popular tools. However, 
compared to the security mechanisms available for e-mail such as PGP [1] and s/MIME [2], text 
messages were sent unprotected in terms of authenticity and confidentiality on the Internet by the 
corresponding IM tools: in the early days, many popular IM solutions like MSN MESSENGER 
and Yahoo Messenger did not provide any security mechanisms at all. AOL only added a 
protection mechanism similar to s/MIME to their IM service later on and Trillian’s SECURElM 
messenger encrypted the data without providing any kind of authentication. Nowadays, most 
clients provide at least client-to-server encryption via TLS. Mechanisms like Off the Record 
(OTR) communication [3] are available that provide among other security properties end-to-end 
confidentiality. 

As the popularity of smartphones grows, the Internet is accessible almost everywhere and 
mobile communication services gained a lot of attraction. IM is one of the most popular services 
for mobile devices and apps like WhatsApp and Skype are among the top downloaded apps 
in the popular app stores. Unfortunately, both applications are closed-source and it is unknown 
which security mechanisms — beside a proprietary or TLS-based client-to-server encryption — are 
implemented. As such, it is hard to assess which kind of security properties are provided by these 
apps and especially end-to-end encryption is missing. In the light of the recent revelations of 
mass surveillance actions performed by intelligence services such as NSA and GCHQ, several 
secure IM solutions that are not prone to surveillance and offer a certain level of security were 
implemented. 

One of the most popular apps for secure IM is TextSecure, an app developed by Open 
WhisperSystems that claims to support end-to-end encryption of text messages. While previously 
focussing on encrypted short message service (SMS) communication, Open WhisperSystems in- 
troduced data channel-based push messaging in February 2014. Thus, the app offers both an 
iMessage- and WhatsApp-like communication mode, providing SMS+data channel or data channel- 
only communications [4], Following Facebook’s acquisition of WhatsApp, TextSecure gained 
a lot of popularity among the group of privacy-concious users and has currently more than 500,000 




installations via Google Play. Its encrypted messaging protocol has also been integrated into 
the OS-level SMS-provider of CyanogenMod [5], a popular open source aftermarket Android 
firmware that has been installed on about 10 million Android devices [6]. Despite this popularity, 
the messaging protocol behind TextSecure has not been rigorously reviewed so far. While the 
developers behind TextSecure have a long history of research in computer security [7]— [12] and 
TextSecure has received praise by whistleblower Edward Snowden [13], a security assessment 
is needed to carefully review the approach. 

In this paper, we perform a thorough security analysis of TextSecure’s protocol. To this 
end, we first review the actual security protocol implemented in the app and provide a precise 
mathematical description of the included security primitives. Based on this protocol description, 
we perform a security analysis of the protocol and reveal an Unknown Key-Share attack, an attack 
vector first introduced by Diffie et. al. [14], To the best of our knowledge, we are the first to discuss 
an actual attack against TextSecure. We also reveal several other (minor) security problems in 
the current version of TextSecure. Based on these findings, we propose a mitigation strategy 
that prevents the UKS attack. Furthermore, we also formally prove that TextSecure with our 
mitigation strategy is secure and achieves one-time stateful authenticated encryption. 

In summary, we make the following contributions: 

• We are the first to completely and precisely document and analyze TextSecure’s secure 
push messaging protocol. 

• We found an Unknown Key-Share attack against the protocol. We have documented the 
attack and show how it can be mitigated. The attack has been communicated with and and 
acknowledged by the developers of TextSecure. We show that our proposed method 
of mitigation actually solves the issue. 

• We show that if long-term public keys are authentic, so are the message keys, and that the 
encryption block of TextSecure is actually one-time stateful authenticated encryption. 
Thus, we prove that TextSecure’s push messaging can indeed achieve the goals of 
authenticity and confidentiality. 

II. TextSecure Protocol 




Figure 1: TextSecure registration. 



We start with a precise description of the protocol implemented by TextSecure. We obtained 
this information by analyzing the source code of the Android app and recovering the individual 
building blocks of the protocol. TextSecure builds upon a set of cryptographic primitives. For 
ECDH operations, these are Curve25519 [15] as implemented in Google’s Android Native Fibrary. 
For symmetric encryption, TextSecure relies on AES in both counter mode without padding and 




cipher block chaining mode with PKCS5 padding. For authenticity and integrity, HMACSHA256 
is used. Security considerations of the cryptographic primitives are not within the scope of this 
paper. 

For push messaging via data channel, TextSecure relies on a central server 1 (TS) to relay 
messages to the intended recipient. Parties communicate with TS via a REST-API using HTTPS. 
T<S’s certificate is self-signed, the certificate of the signing CA is hard-coded in the TextSecure 
app. Actual message delivery is performed via Google Cloud Messaging (GCM), which basically 
acts as a router for messages. 

A. TextSecure Protocol Flow 

TextSecure’s protocol consists of several phases. We distinguish (i) registration, (ii) send- 
ing/receiving a first message, (iii) sending a follow-up message, and (iv) sending a reply. 

Before a client is able to communicate, it needs to generate key material and register with TS. 
When a party V a first decides to use TextSecure’s data channel communication, it chooses an 
asymmetric long-term key pair ( a,g a ), referred to as identity key by TextSecure’s developers. 
It also uses SHA1PRNG as provided by the Android Native Library to choose a password (pw), 
a registration ID (reglD a ), and two keys k enC:S , gna i t0 , fc moc . S! ; 9rto ;. a , each of 128 bit length. 
Additionally, the client chooses 100 asymmetric ephemeral key pairs, so-called prekeys, and one 
asymmetric last resort key (k\ t ). When a party calculates a message authentication code (MAC), 
it uses HMACSHA256 as implemented by Android’s respective Native Library. 

For a party V a to send a message to a party Vi>, V a requests one of TVs public prekeys 
from TS, uses it to derive a shared secret, forms a message, whereof parts are encrypted and/or 
protected by a MAC, authenticates with TS, and transmits the message to TS. TS shares a 
symmetric long-term key (k enc ^i gna i ib , k mac , signal, b) with TV which it uses to encrypt all parts 
of TVs message that are to be transmitted to 7V TS then hands off this encrypted message to 
GCM for delivery to TV If V„ wants to send a follow-up message to TV it derives a new key 
using a function / that is seeded with existing key material. When a party does not merely send 
a follow-up message, but a reply within a conversation, it also introduces new entropy into the 
seed of / and transmits a new ephemeral public key. 

B. Detailed Description of Messages 

In the following we give a detailed description of messages sent and processed in the different 
phases, as well as the key derivation. 

1) Registration: The registration process is depicted in detail in Figure 1. To register with 
TextSecure, a party V a requests a verification token by transmitting its phone number (phone# a ) 
and its preferred form of transport to TS (Step 1), which TS confirms with a HTTP status 204 
(Step 2). Depending on the transport V a chose, TS then dispatches either a short message or a 
voice call containing a random token (Step 3) to the number transmitted in Step 1. V a performs 
the actual registration in Step 4, where it shows ownership of phone# a by including the token, 
registers its credentials with the server via HTTP basic authentication [16], and sets its signaling 
keys. In this step, the client also states whether it wishes to communicate only via data channel 
push message or also accepts short messages. The server accepts if the token corresponds to the 
one supplied in Step 3 and the phone number has not been registered yet. 

In Step 6, V a supplies its 100 prekeys and k\ r to TS. Prekeys are not transmitted individually, 
but within a JSON structure consisting of a key ID z, a prekey g x,: -', and the long-term key g a . 
The last resort key is transmitted in the same way and identified by key ID OxFFFFFF. The server 
accepts, if the message is well-formed and HTTP basic authentication is successful. V a then 
registers with GCM (Step 8) and receives its regl Df cm (Step 9), which it transmits to TS in 
Step 10 after authenticating again. 

2) Sending an Initial Message: We define the period in which V a employs one prekey to 
communicate with V b as a session. When a new session is created to exchange messages, three 
main cryptographic building blocks are applied: a) a key exchange protocol with implicit authen- 
tication to exchange a secret, b) a key update and management protocol (the so-called axolotl 
ratchet [17]), which updates the encryption and MAC keys for every outgoing message, and c) a 
stateful authenticated encryption scheme. The process is depicted in detail in Figure 2. 

1 textsecure- service.whispersystems.org 




Intuitively, the key exchange is a triple Diffie-Hellman (DH) key exchange using long-term 
and ephemeral secret keys. This is the only step in the protocol flow that uses the long-term keys. 

According to the developers [17], the key management protocol provides both forward secrecy 
(which roughly means that past sessions remain secure even if the long-term key of a party is 
corrupted) and future secrecy (which translates to the idea that even after leakage of a currently 
used shared key future keys will remain secure). 

The result of the key exchange and key management is input to the stateful authenticated 
encryption scheme [18]. The state of the encryption scheme is provided by the key management 
system and handed over from every call of the encryption and decryption algorithm, respectively, 
to the next for the whole session. Every new message is encrypted under a fresh key. The scheme 
guarantees confidentiality and authenticity of the exchanged messages, which we discuss in detail 
in Section IV. 




Figure 2: Sending an initial TextSecure message. 



a) Key Exchange: In the first step, V a requests a prekey for Vi, and receives a JSON 
structure consisting of prekeylD z, a prekey g Xbz , and TV s long-term key g b . V„ also receives 
reglD b from TS an then chooses a new ephemeral key to calculate a secret as the concatenation 
of three DH operations, combining TV s prekey, TVs long-term key, TVs long-term key, and TVs 
freshly chosen ephemeral key. 

b) Key Management (axolotl ratchet): After V a has completed the initial key exchange, it 
derives two symmetric keys ( ksA,r,kBA,c ) for receiving messages using / (cf. Algorithm 1). / 
is here seeded with secret. For all respective parameters of / see Figure 2. V a then chooses a 
new ephemeral keypair (x a ,ii <? Xo,1 )> which is never used and just exists because of reuse. It then 
chooses another ephemeral keypair (x a y, g x "' 2 ), which it uses to calculate Shared as the output 
of a DH operation that takes TVs prekey g Xb - z and x Q ,2 as input. V a then derives two symmetric 
keys (kAB,r,kAB,c) for sending messages. Here / is seeded with fc sharc d and knA.r- Finally, V a 
uses /, seeded with . to derive the message keys (k Enc , k MAC ) and in the end derives a new 
kAB,c as MACfc AB c (const2), where const2 = 0x02. 



Algorithm 1 / (input, key, string) 

k pr <— MAC key (input) 
ko <- MAC kpr (string, 0x00) 
ki <- MAC kpr (ko, string, 0x01) 
return (fc 0 , fei) 



c) Stateful Authenticated Encryption: A message to € M is encrypted using AES in counter 
mode without padding as c = ENC^ (m). V„ then forms message (3.) and thus calculates 
tag = MACk MAC (x), where x = (v,g Xa ' 2 ,c\x a ,pcXx a ,c). v represents the protocol version and is 




set to 0x02. For ordering messages within a conversation ctr and pctr are used. Both are initially 
set to 0. ctr is incremented with every message a party sends, while pctr is set to the value ctr 
carried in the message a party is replying to. 

Upon receiving message (3.), TS checks if reglD b corresponds to phone# b . It then encrypts 
the parts of message (3.) intended for Vb with TVs signaling key, using AES in CBC mode with 
PKCS5 padding. TS additionally calculates a MAC over the result, which we denote as mac signal . 
TS sends both, encrypted message data c signal and mac signal , to the GCM server, together with 
reglD b cm as the receipient. The result of this additional encryption layer is that Google’s Cloud 
Messaging servers will only be able to see the receipient but not the sender of the message. 

The receiving process is depicted in Figure 3. Vb receives the message in Step (5.). First, Vb 
verifies mac slgnal and, if successful, decrypts c slgnal . It looks up its private key that corresponds to 
prekeylD 2 and calculates secret. 

Vb then derives two symmetric keys (knA.r-, knA.c) for sending messages by seeding / 
with secret. Afterwards, Vb calculates Shared as the output of a DH operation that takes TVs 
latest ephemeral key g x ° 2 and TVs private prekey x b z as input. In the next step Vi, uses 
/ (^shared, constij) to derive two symmetric keys (kAn.r, kAn.c) for receiving messages 

and derives the message keys (k Enc , k MAC ). 

Vb now verifies the MAC and, if successful, decrypts the message. In the end, T \ also derives 
a new T;ab,c = MAQ ab c (const2). 

3) Follow-up Message: If V a follows up with a message before Vb replies, V„ derives a new 
pair (k Enc , k MAC ) = / (MAQ. 4/i i . (consti) , consto, const ^j, which it then uses as detailed above. 

4) Reply Message: If Vb wants to reply to a message within an existing session with TV it 
first chooses a new ephemeral keypair (x b .o ; V 6,0 ) and calculates fc S hared as the output of a DH 
operation that takes TVs latest ephemeral public key g x "- 2 and its own freshly chosen ephemeral 
private key Xb,o as input. Vb then derives (knA.r, knA.c) by seeding / with Shared and k.An.r- 

C. Key Comparison 

In an attempt to establish that a given public key indeed belongs to a certain party, TextSe- 
CURE offers the possibility to display the fingerprint of a user’s long-term public key. Two parties 
can then compare fingerprints using an out-of-band channel, for example, a phone call or an in- 
person meeting. If two parties meet in person, TextSecure also offers to conveniently render 
the fingerprint of one’s own long-term public key as a QR code, using a third-party application on 
Android, which the other party can then scan using the same application on their mobile device. 
TextSecure then compares the fingerprint it just received to the party’s fingerprint it received 
as part of a conversation. Figure 4 pictures these fingerprints. 

III. Issues with TextSecure 

Based on the recovered protocol description, we can analyze its security properties. In the 
following, we discuss our findings. 

A. MAC Image Space Only Partially Used 

In Section II, we stated that TextSecure uses HMACSHA256 to calculate MACs. Sur- 
prisingly, TextSecure does not transmit the complete output of HMACSHA256. The message 
tag in Figures 2 and 3 does only represent the first 64 bit of the 256 bit MAC. Upon request, 
TextSecure’s developers stated that this just happens to reduce message size. However, SHA256 
has been designed to achieve its security goals with an output length of a full 256 bit. While 
Biryukov et al. [19] analysed the security of reduced -round SHA256, to the best of our knowledge, 
the security of a reduced -length SHA256 has not been investigated, yet. However according to 
NIST [20, chapter 5.5], a MAC length of 80 bit is recommended when a MAC is used for key 
confirmation, which is the case in TextSecure (at least) in the first message of a new session. 





get prekey: Xf, >z 

secret = , g*:*-**) 

( kBA,r , ksA, c ) = f (secret, consto, const#) 

^shared = 9 ~ a ’ 2 b,z 

( k,AB,r , kAB,c ) = / (^shared) ksA,ri Const#) 

(k Enc , k MAc) = / (MAC feAB>c ( const i) , const 0 , const#) 

tag" = MAC k|viAc (x) * 

if tag" = tag then: 

m = DEC kEnc (c) 

kAB, c = MAC kABc (const 2 ) 



Legend: 

consto = OxQO 32 
const i = 0x01 
const 2 = 0x02 

const# = ” Whisper Ratchet” 
const# = ” WhisperMessageKeys” 

Figure 3: Receiving an initial TextSecure message. 



B. Uncommon Usage of H MAC 

The standardized HMAC construction that builds a MAC from a cryptographic hash function 
is detailed in RFC 2104 [21], The security of HMAC, given properly applied, uniformly random 
keys, is well analyzed in the cryptographic literature [22]— [24] . 

We observe that in TextSecure HMAC is used in a uncommon manner. Consider Algorithm 
1 (in the following abbreviated by /) that is used multiple times for key derivation in TextSecure 
and that calls HMAC three times. For example, / is first called with (secret, consto, const#) as 
parameters. Note that the only unknown (and uniformly distributed) value here is secret. Thus, 
we would expect secret to be the key when HMAC is called by /. Surprisingly, the following 
happens: / initially sets k pr <— HMAC consto (secret). Here, the publicly known constant consto 
is set to be the key of HMAC. After that ko <— HMACfc j r (const*), using k pr as key of HMAC is 
evaluated. Given the standardization of HMAC one would expect k pr to be computed as k pr <— 
HMAC S ecret (consto). If this was the case, we could apply well-established methods from the 
cryptographic literature [22]— [24] during the security analysis. However, due to this uncommon 
application of HMAC these results cannot be applied and in particular we do not know whether 
the PRF-property of HMAC is preserved. We do not know if this can be exploited in pratice. Still, 
we stress that this usage of HMAC is quite uncommon. 

C. Unknown Key-Share Attack 

An Unknown Key-Share Attack (UKS) is an attack vector first described by Diffie et. al. [14], 
Informally speaking, if such an attack is mounted against V a , then V a believes to share a key 
with Vb, whereas in fact V„ shares a key with V e f TV 

For a better understanding how this can be related to TextSecure, suppose the following 
example: Bart CP;,) wants to trick his friend Milhouse (P a ). Bart knows that Milhouse will invite 
him to his birthday party using TextSecure (e.g., because Lisa already told him). He starts the 
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Their identity (they read): 

05 20 31 b6 81 67 7d d5 
dO e4 aO e4 8a 37 27 73 
cd 11 75 44 22 7d 6a c2 
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7c b9 fa 68 a9 49 7c be 
3e a2 8d 94 5d 53 bd ce 
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(a) Conversation fingerprints (b) Own fingerprint QR code 

Figure 4: TextSecure fingerprint verification. 



UKS attack by replacing his own public key with Nelsons (V e ) public key and lets Milhouse verify 
the fingerprint of his new public key. This can be justified, for instance, by claiming to have a 
new device and having simply re-registered, as that requires less effort than restoring an encrypted 
backup of the existing key material. Now, as explained in more detail below, if Milhouse invites 
Bart to his birthday party, then Bart may just forward this message to Nelson who will believe 
that this message was actually sent from Milhouse. Thus, Milhouse (V a ) believes that he invited 
Bart (' Pb) to his birthday party, where in fact, he invited Nelson ( V e ). 




Figure 5: UKS attack on TextSecure: V a believes to share a key with Vb but shares one with 

V e . 



In detail, the attacker (Bart, Vb) has to perform the steps shown in Figure 5 for this attack 
(only the important protocol parameters and steps are mentioned): 

(1-2) Vb requests g Xe - z o , . . . , g x *-*i from TS using phone# e . 

(3-4) Vb commits g Xe > z o , . . . , to TS as his own prekeys plus </' as its own long-term 
public key. 

(5) Vb lets V a verify the fingerprint of its new public key g e . Note that this step uses QR-codes 
is is thus offline. 

(6-7) Once V a wants to send the message to Vb, V a requests a prekey for Vb by using phone# 6 . 
TS returns g Xhz i = g x, ' z < and the long-term key g b = g e . 



(8-9) V a computes the secret using g Xb ' z i and g b from which (k Enc AB , k MAC AB ^j are going 
to be derived. For computing those keys, he uses in fact TVs prekey and idenity key 
although he believes to use TVs ones. He then encrypts message in € M, computes the 
respective MAC tag, and sends it to V b (GCM ommited). 

(10-11) Vb is neither able to verify the tag nor to decrypt the message c. He sends the ciphertext 
and message tag to V e . 

(12) V e processes the incoming message as usual. He computes the same secret as V a , because 

g x b , Zj _ g x e , Zj and gb =g e 

The secret is then used to compute (k EncAB = k Enc AB , k MAC = k MAC AB J so that 
V e is able to read and verify the message. 

In Step 10, Vi, has to forward the message to V e , such that it appears to be sent by TV 
Therefore, he needs to include authentication a for TS to include phone# a in Step 11, so that 
V e will receive phone# a with the forwarded message. This can be achieved in several ways: 

• TS is corrupted. In this case, it is a trivial task to get or circumvent authentication a . 

• If TS is benign, an attacker might be able to eavesdrop authentication a . Although TLS 
is used for all connections between clients and server, future or existing issues with TLS 
implementations [25]— [29] can not be ruled out and would allow for a compromise of 
authentication 0 . Another possibility to obtain authentication a could be a governmental 
agency (legally) enforcing access to the TLS keys. 

• In contrast to a party’s other key material, the password is stored unencrypted and is 
not protected by TextSecure’s master password. Thus, the easiest possibility to realize 
this attack might be for an attacker to recover the password for authentication a from 
TextSecure’s preferences 2 . 

Devices are left unattended on tables in bars and clubs, users can be compelled to hand 
devices over in a traffic control, stop-and-frisk operations, immigration and customs, or 
when passing through airport security. The widely used Android Unlock Pattern has been 
shown to be a weaker protection than a three-digit PIN [30] and can often also easily be 
recovered from the smudges a user leaves on the screen during the unlock process [31]. 

D. Unknown Key-Share Attack Variant 

In this variant, there is no need for the attacker to know authentication a . Instead, he must only 
be able to stop/intercept one message, for example, by controlling one active network element in 
the path between V a and TS, like a WiFi accesspoint. 

The attack from the previous section makes V a (the sender of a message) believe he shares 
a key with Vi, (intended receiver of that message) while he in fact shares a key with V e (actual 
receiver of the message). To this end, V\, had to replace his own public key by the public key of 
the intended receiver. 

An attack on V e is also possible, using similar techniques: Suppose the attacker replaces his 
own public key with the public key of the sender. Then any message that is sent from V„ to V e 
may also originate from TV This makes V e (the receiver) believe in that he shares a key with Vi, 
(claimed sender) while he actually shares a key with V a (actual sender). 

This is a practical issue in competitions where, for instance, the first to send the solution to 
V e wins a prize. 

To mount such attack using TextSecure, V b replaces his own public key with the public 
key of V a and lets V e verify it. We stress again that replacing the public key and letting V e verify 
it is not an issue for Vi, in practice. Now, when V„ starts a new session with TV Vi, can mount 
the attack by intercepting the message sent from V a to V e . He relays the message to TV but uses 
his own authentication*,. 

2 File: shared-prefs/org.thoughtcrime.securesms _preferences.xml 




E. Mitigation of Unknown Key-Share Attack 

Let us consider the message that is sent in Step 8 of Figure 5: 

X, tag, g *°-° , g a , reglD 0 , reglD e , 
phone# e , authentication^ 

where x = ( v > g Xa/2 , ctr a , pctr a , c) and tag = MACk MAC (x). Intuitively, if both V a ’s and Vfs 
identity were protected by the tag, then the attacks above do not longer work. As identities we 
propose to use the respective parties’ phone numbers, as they represent a unique identifier within 
the system, x would thus be formed as 

(v, < 7 x °’ 2 ,ctr a ,pctr a , 

phone# a , phone# e , c). 

If k MAC is secret (i.e., only shared among V a and V e ) and if MAC is secure, the inclusion of both 
identities in the tag provides a proof of V a towards V e that V„ is aware of V e as its peer, i.e., 
that the message is indeed intended for V e . Moreover, V e is convinced that V a actually sent the 
message. Thus, Vi, will not be able to mount the above attacks. 

Remark 1. Our mitigation resembles the concept of strong entity authentication [32], However, 
this concept is not directly applicable here, since we consider asynchronous message exchange. 

F. No Cryptographic Authentication 

While the Unknown Key-Share Attacks are mitigated if the message in Step 8 is modified as 
we propose in Section III-E, the underlying problem is not resolved. It results from a party’s 
erroneous assumption that a communication partner’s long-term identity key is authentic, if they 
have compared key fingerprints and these fingerprints matched their assumptions. However, this 
is not necessarily the case. Given the attack scenario in Section III-C, a malicious party would 
always be able to present a third party’s long-term public key as their own, as only fingerprints 
are compared - a party is not required to show their knowledge of the corresponding secret key. 

G. Mitigation of Authentication Issue 

In the following, we present two means of authentication. The first one provides a mutual 
cryptographic authentication with the help of digital signatures, while the second one achieves 
this goal requiring less effort in terms of implementation and also integrates seamlessly into 
TextSecure’s existing user experience. 

1 ) Signature-based Cryptographic Authentication: V a and 'Pi, can establish the authenticity of 
their respective long-term keys as follows 

1) V a choses a token r a g r SHA1PRNG[128] and presents a QR code containing r a- 

2) Vb scans this QR code, creates a signature o over r a using his long-term private key, chooses 
a token tb €r SHA1PRNG[128] and creates a QR code containing both the signature over 
Va and his own token. 

3) V a scans the QR code presented by Vb and verifies o with respect to r a using Vfs long-term 
public key. V a then creates a signature a' over {vbU'a ) using his long-term private key and 
creates a QR code containing o’ . 

4) Vb scans the QR code presented by V a and verifies a’ with respect to (r#, ta) using V a ’s 
long-term public key. 

If the verification in Step 3 is successful, V a is assured that Vfs long-term public key is 
authentic and Vb does know the corresponding private key. Likewise, if the verification in Step 4 
is successful, Vb is assured that V a ’s long-term public key is authentic and V„ does know the cor- 
responding private key. In comparison to simply reading out or scanning two fingerprints, a mutual 
cryptographic authentication that also requires to demonstrate knowledge of the respective private 
key requires the creation of one additional QR code and thus one additional scanning process. 
Though we believe that the above solution works it requires some overhead since signatures are 
not included in TextSecure, yet. Therefore we propose another mitigation in the next section 
(and analyze it in section IV) that blends well with the cryptographic primitives that are already 
implemented in TextSecure. 




2) Alternative Authentication Method: The challenge response process detailed below can be 
modified to achieve cryptographic authentication with the primitives already used in TextSecure. 
The process is as follows: 

1) Vb chooses a keypair (r, g r ) Gr Z p x Curve25519. It creates a QR code containing chall = g r . 

2) V a scans the QR code, derives resp = chall" (= g r ' a ) and creates a QR code containing 
resp. 

3) Vb scans the QR code presented by V a and checks if g a r = ? resp. 

If resp, matches g a r , Vb is assured that V„ knows the private key corresponding to the long- 
term public key that Vi, expected to belong to V a - If resp ^ g b r , the authentication fails. Here, 
we call V a prover and Vb verifier. The process can then be repeated with reversed roles to achieve 
mutual authentication of Vb and V a - We discuss the security of this approach in detail in the 
following section. 

IV. Security of TextSecure Key Exchange and Messaging 

As mentioned in Section III, the underlying problem that allows for our attacks is that the 
shared key between two parties is not cryptographically authentic. In the same section we explain 
how to face this problem. In this section we first show that the method proposed in Section III-G2 
actually solves this issue (under some reasonable restrictions). Next, we show that if public keys 
are authentic then so is k = (k Enc . k MAC ). Moreover we show k to be uniformly distributed. 
Once we have established this, we finally show that the encryption block of TextSecure is 
actually one-time stateful authenticated encryption (a primitive which needs uniformly distributed 
and authenticated keys to provide security). 
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Figure 6: Challenge and Response security game. 



A. Offline Verification gives authenticity 

In this section, we prove the proposed protocol of Section III-G2 to be secure. Ideally, we could 
prove the possession of the secret key through a zero knowledge proof of knowledge. However, 
we do not know if the protocol satisfies this strong property. Rather we prove that if an “honest” 
verifier accepts, then with high probability the prover’s public key is unique. Since the public 
key is later on used in the means of authentication, this gives authenticity. Note that we do not 





consider collusion of parties that deliberately agree to use the same long-term key pair here. In 
this case, attacks as above are always possible. We assume in the following that no two parties 
collude. 

Consider the security game that is depicted in Figure 6. We say that an attacker (t, e)-wins 
the security game if it runs in time t and C outputs 1 with probability at least e. We argue that 
this security game actually models malicious behaviour of an adversary convincing an “honest” 
verifier to have public key g". To this end, suppose that A publishes the public key g a that 
is already registered as the public key of V a as its own public key. If C returns 1, then A is 
obviously successful in convincing a party that follows the protocol honestly that g a is authentic 
with respect to A (which it is not). However, if the probability that A succeeds in the security 
game is small then this is not very likely to happen which means that g a is registered only once 
with overwhelming probability 3 . We note that we do not allow the adversary to challenge back the 
challenger. This somewhat artificial restriction is due to the fact that we cannot prove the scheme 
to be secure without this requirement (see below). We remark, however, that this protocol is carried 
out when prover and verifier meet face-to-face and, moreover, that no data is sent through the data 
channel. Thus, the adversary is not a network attacker and in particular has not the capability to 
read, replay, delay, alter, or drop any data that is exchanged throughout a protocol run between 
two honest parties. A proving party will always be able to confirm who the verifier actually is 
and may refuse to prove something to a seemingly malicious verifier. 

Technically, if we wanted to get rid of this requirement we could use an IND-CCA-secure 
KEM that supports public keys of the form g a in elliptic curves, e.g. the PSEC-KEM that is 
standardized by the ISO [33] and proven to be secure by Shoup [34] in the random oracle model. 

Claim 1. If there is an attacker A that ( t,e)-wins the above game (cf Figure 6) then there is an 
algorithm B that (t 1 . e')-breaks the DDH assumption in Curve25519 where t ~ t' and e < e' . 

Proof: Suppose A wins the game with probability e. We construct a DDH-distinguisher B 
that runs A as a subroutine. B gets as input (g, g a ,g b ,g 1 ) and wants to distinguish whether 7 = ab 
or not. B simulates C as follows: It creates a QR code containing g b . If A creates a QR code 
containing g 7 then 7 = ab and thus B is able to solve DDH. ■ 

B. (k Enc , k MAC ) is authentic. 

Now let us assume public keys are unique. We argue that in this case k = (k Enc , k MAC ) 
authenticates sender and receiver since these are the only parties to compute k. 

Here, we show that the sender ( V a ) is authenticated. The proof for the receiver is similar. To 
this end, we define the following algorithm that reflects key derivation (for the first message sent 
during a session) on the side of the receiver (' Pf) where g a , g x "’° and g Xa2 are long-term and 
ephemeral public keys of V a , b is the long-term secret of Vi, and z is a pointer to the prekey pair 
(■ x b ,z,g Xb ■*) (cf. Figure 3). 



Algorithm 2 Key.deri ve (g a , g Xa ’° , g Xa ’ 2 ,b, z) 

secret «- / [ g ^ a , g b ^. *■*«,<>) 

(k B A, r , k B A, c ) f (secret, const 0 , const R ) 

^shared g Xa ' 2 ' Xb ’* 

{kAB,r, kAB,c) f (^shared; kAB,r, Const r) 

k <- f ( MAC(kAB,c consti), consto, const*-) 



Let us now consider the security game that is depicted in Figure 7. We say that A (t, e)-wins 
the security game if it runs in time at most t and C returns 1 with probability at least e. We argue 
that this security game acutally models authenticity of k. To this end, suppose again that g a is 
the public key of V„ f A. Note that this public key is unique. It is given to A, together with the 
public key g b and a prekey g Xb - z of party TV, by computing k. The goal of A is to impersonate A 
to Vb. If A is able to succeed, then it may obviously break the authenticity property. On the other 
hand, if the probability for A to succeed is small it is very unlikely for A to compute the shared 
key of two honest parties V„ and Vb- By the uniqueness of public keys this gives authenticity. 



^Observe that the probability that two parties following the protocol honestly publish the same public key is 
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Figure 7: Authenticity of k security game. 



Claim 2. If an attacker A ( t,e)-wins the above security game (cf. figure 7), then there is an 
algorithm B that {f . e')-breaks the CDH-assumption in Curve25519 where twt' and e < e'+gtre- 
The analysis will view the functions f and MAC as a non-programmable random oracle [35], 

Remark 2. As discussed in Section III-B, we do not know if f and, in particular, MAC preserve 
the PRF -property o/HMAC. This is why for the proof of claim 2 we resort to a non-programmable 
random oracle. 

Proof: We describe a CDH-forger B that runs A as a subroutine. B gets as input ( g , g° ,g Xh z ) 
and wants to compute g aXb ^. It samples b <— Z p and sends {g a ,g b , g Xh z ) to A. Note that B is not 
able to compute Key. derive. Instead we let B always return 0. We argue that with overwhelming 
probability this will not be detected by A: We observe that since / is modeled as a random 
oracle (and thus the image of / is uniformly distributed over {0, l} 512 ) for A to tell the value of 
k it needs to query / on MACfc AB c ((consti), consty. const /<-) since otherwise the value of k is 
information-theoretically hidden from A. The same argument applies for the value of MACa 4JJ c 
( which is needed to compute k), kn.A.r (which is needed to compute kAB,c) and secret (which 
is needed to compute ksA,r )• Now, suppose A queries / on secret = (g a ' Xb - z , g bx *,o , g x >< * 
for some :r Q ,o- Since / is modeled as a random oracle, the query of A is actually public and thus 
B can extract g°' Xb < z , the solution to the CDH instance. Thus, if CDH is hard in Curve25519 for 
A, to be successful, A needs to correctly guess a bitstring of length 512. This probability can be 
neglected. ■ 

We immediately obtain that k is not only authentic but also uniformly distributed. Now, a 
similar (information theoretic) argument applies to keys that are derived from k for the next 
messages to be sent and received. 

We stress that for our proof to be bootstrapped to the setting with more than one prekey of Vb, 
these have to be pairwise distinct (i.e., unique) since otherwise replay attacks become possible. 
In particular, Claim 2 does not apply to keys exchanged relying on the last resort key. 

C. TextSecure Encryption is One-time Stateful and Authenticated 

Next, we prove the actual encryption of TextSecure to be one-time stateful authenticated 
encryption. We stress that one-time security suffices for TextSecure since, here, the actual 
encryption and MAC keys are updated (and can be seen as fresh, cf. previous section) with every 
message to be sent. 





1) Cryptographic Primitives: We shortly recall the cryptographic primitives that are used by 
the TextSecure encryption procedure. 



A message authentication code is a pair of PPT algorithms MAC = (Tag, Vfy) such that tag <— 
Tag (fc, m) on input a key k and a message m returns tag for that message. The algorithm {0, 1} «— 
Vfy(fc, to, tag) returns Tag(fc, to) = tag. We require the usual correctness properties. Following 
Bellare et al. [22], [36] we say that an attacker A (f, e)-breaks the strong one-time security of 
MAC if it runs in time t and 



Pr 



(tag, to) 



£ ^Tagtfc,) . 



Vfy(fc,TO,tag) = 1 
A (tag, to) ^ (tag', to'). 



where A is allowed to query Tag at most one time (the query is denoted by nn! and the response 
by tag 7 ). 



A symmetric encryption scheme is a pair of PPT algorithms SE = (Enc, Dec) such that c <— 
Enc(/e, to) on input a key k and a message to returns a ciphertext c and m «— Dec(fc, c) on input 
a key k and a ciphertext c outputs to. We require the usual correctness properties. We say that an 
attacker A (t. e)-breaks the one-time IND-CPA-security [37] of SE if it runs in time t and 

Pr [& 7 A ^ 4 Encr ypt(-,-) . b = > e 



where A is allowed to query Encrypt at most one time on two messages too and toi of equal 
length and Encrypt samples a uniformly random bit b and returns c t— Enc(fc, mb). 



2) Stateful Authenticated Encryption in TextSecure; A stateful encryption scheme Ste is a 
pair of PPT algorithms Ste = (Ste. Enc, Ste. Dec) with the following syntax: 



• The encryption algorithm outputs a ciphertext C and a state st' on input key k, associated 
data hd, message m and a state st, ( C,st ') A Ste.Enc(/c, hd, to, st). 

• The deterministic decryption algorithm outputs a message to and a state st' on input a 
key k, associated data hd, a ciphertext C and a state st, (to, st') t— Ste.Dec(fc, hd, C, st). 
Ste. Dec may also return _L indicating a decryption error. 



For TextSecure we let hd contain at least {g Xa - 2 , reglD a , reglD b ), the ephemeral public key 
of party V a , and the identifiers of both parties. The state is set to (ctr, pctr) and is initialized 
to (0,0). For practical purposes it is important that these are handed over carefully to the next 
execution of encrypt and decrypt, resp. The key is set to be k = (k Enc , k MAC ) handed over by the 
ratchet protocol. 



Algorithm 3 TS.Enc (k,hd,m,st) 
c Enc kEm (m) 

X <- (v,g Xa ’ 2 , ctr a , pctr a , c) 
tag «- MAC kMAc (x) 

ctr + + 

return (x, tag, st) 
c 



Algorithm 4 TS.Decffc, hd, C, st) 



parse C as C = (x', tag 7 ) 

parse x' as x' = / (v\ ( g Sa ’ 2 )' , ctr 7 a , pctr 7 a , c 7 ) 

X" <- W, (g Xa ' 2 )' , pctr b , ctr 6 , c 7 ) 

tag 77 <- MAC w (x 77 ) 

if tag 77 f tag' return (_L,±) 



to i- Dec kEnc (c) 

if to = _L return 
pctr + + 
return ( m,st ) 




Security of a Stateful Authenticated Encryption scheme Ste is captured through a security game 
that is played between a challenger C and an attacker A, as implicitly mentioned by Paterson et 
al. [18] and explicitly by Jager et al. [38]. 

• The challenger samples b {0, 1} and a key k -t— 1C. It initializes states and sets 
i = ctr — 1 and j = pctr — 1 (This way it is guaranteed that C* = C c t, a whenever a 
ciphertext is generated by a and similar for b ). 

• The adversary may then query each of the Encrypt and Decrypt oracles once and they 
respond as depicted in Figure 8. 

• Finally, A outputs a bit b' and wins if b = b' . 

Encrypt(?no, mi, hd) 
i = i + 1 

(C°, st° ) Ste.Enc(fc, hd, m 0 , st ) 

(C 1 , st 1 ) A Ste.Enc(fc, hd, mi,st ) 
if C° = _L V C 1 = _L: return _L 
(Car, Ste) ( C b ,St b ) 

return C, 

Decrypt(C, hd) 

3=3 + 1 

(m, st) <- Ste.Dec(/c, hd, C, st) 
if j > i V C ± Cj : div «- 1 

if div = 1 A b = 1 return m 
return _L 

Figure 8: Encrypt and Decrypt Oracles in the Stateful Authenticated Encryption security game. 

Since the behaviour of oracle Decrypt might not be clear at first sight, we will shortly explain 
it. First, we recall that the goal of the adversary is to determine the bit b. Stated otherwise, if the 
adversary queries Encrypt on two distinct messages of equal length its goal is to determine which 
message is encrypted. Oracle Decrypt will reveal this information to A if either A manages to 
query Decrypt for a ciphertext that is not authentic, i.e., C f Cj or that is in the wrong order, 
i.e., j > i and that nonetheless does not incur in a decryption error. 

Theorem 1. If there is an attacker A that (£, e)-breaks the one-time stateful authenticated en- 
cryption security o/TS.Ste then there is an attacker £>mac that (£i, ef)-breaks the strong one-time 
security of MAC and an attacker £>Enc that (£2, cf -breaks the one-time IND-CPA security of the 
encryption scheme where t « t\ « £2 and 

e < ei + e 2 

Proof: The proof is by a sequence of games. First, we will modify the Decrypt oracle such that 
its response will be independent of b. If the MAC scheme is secure this change will be undetected 
by A. After that we will rely on the security of Enc to argue that A has only negligible advantage 
in telling the value of b. By Q we will denote the event that A is successful in Game i. 

Game 0. This is the real Stateful Authenticated security game as described above. Thus, we 
have: 

Pr[Co] = e 

Game 1. In Game 1, the challenger proceeds as follows: When the attacker queries a ciphertext 
C to the decryption oracle, C always outputs _L. Except for this, C proceeds exactly as in Game 0. 
Note that Decrypt will return always _L if div = 0 (i.e., conditioned on div = 0 Game 0 and Game 
1 are identical) and will return m only if div = b = 1. Now, if div = 1 then j > iV C f Ci . 

j > i : If j > i (i.e. Decrypt is called by A before Encrypt) and decryption does not return 
_L then the ciphertext C that was queried to Decrypt by the adversary contains a valid tag which 
contradicts the one-time security of MAC. 





C f C :i : If C f Cj then a similar argument applies to show that decryption will fail and thus 
return _L: Here, we reduce to the strong one-time security of MAC. (Recall that strong one-time 
security requires that it is computationally infeasible to compute a valid tag, tag', for message m, 
even if a valid tag, tag, for message m is known.Thus Thus, we have: 

Pr[Co] - Pr[Ci] < ei 



Game 2. In Game 2, instead of encrypting mb, C samples a random message m, computes 
( C,st ) TS.Enc (k,hd,m,st) and returns C. This change does not affect oracle Decrypt since 
due to Game 1 it will return _L anyway. Now, by the IND-CPA-security of Enc this goes unnoticed 
from the adversary. Thus, we have: 

Pr[Ci] - Pr[<2] < e 2 

Claim 3. Pr[C2] = 0. 

Proof: In Game 2 the Decrypt oracle reveals no information about b due to Game 1. Neither 
does the Encrypt-oracle due to Game 2. The claim follows. ■ 

D. Summary 

In this section, we showed that our improvement of the TextSecure protocol mitigates the 
UKS attacks. Therefore we showed, that the protocol from section III-G2 proves long-term public 
keys to be unique, i.e., that with overwhelming probability no two parties share the same public 
key (except if they collude). Then we proved that (k Enc , k MAC ) are bound to the respective long- 
term keys of the parties which gives authentic keys (that are also uniformly distributed). Finally, 
we established that TextSecure encryption is actually one-time stateful and authenticated. If 
the encryption and decryption states are carried over carefully from one call of the encryption and 
decryption procedure to the next, this shows that TextSecure achieves stateful authenticated 
encryption. 



V. Related Work 

The body of work that explicitly aims at providing or analyzing secure instant messaging 
protocols is comparably small to the prevalence of instant messaging applications in our daily 
life: At the 2004 Workshop on Privacy in the Electronic Society (WPES), Borisv et. al. [3] 
presented a protocol for “Off the Record” (OTR) communication. The OTR protocol was designed 
to provide authenticated and confidential instant messaging communication with strong perfect 
forward secrecy and deniability : no party can cryptographically prove the authorship of a message. 
The deniability property of OTR has been discussed by Kopf and Brehm [39]. The work of Di 
Raimondo et. al. [40], who analyzed the security of OTR, is in its nature closely related to our 
paper. The authors point out several issues with OTR’s authentication mechanism and also describe 
a UKS attack on OTR, as well as, a replay attack along with fixes. We note, however, that the 
authentication mechanisms of OTR and TextSecure have little in common: Though it aims to 
provide deniability, OTR explicitly uses signatures for authentication while TextSecure does 
not. The UKS attack on OTR described by Raimondo et al. [40] directly targets the key exchange 
mechanism of the protocol, whereas the attacks presented in this paper are rather subtle and exploit 
the protocol structure and key derivation of TextSecure. 

Besides OTR, which has been widely adopted, there exist protocols for secure instant messaging 
like IMKE [41], which aim at being verifiable in a BAN-like logic, but has never found a wider 
adoption. SILC [42] also has received a certain adoption and some discussion, but is rarely used 
today, as is FiSH [43], a once popular plugin for IRC clients that used Blowfish with pre-shared 
keys to encrypt messages. 

Thomas [44] analysed the browser-based instant messager Cryptocat and found that, due to 
an implementation error, Cryptocat used private keys of unsufficient length when establishing a 
group chat session. Green [45] recently discussed Cryptocat’s group chat approach from a protocol 
perspective and points out several issues. 

Further protocols exist that aim at securing instant messaging communication but have, to the 
best of our knowledge, not received public scrutiny. Among these are Threema [46], Surespot 
[47], and Silent Circle’s SCIMP [48]. 




VI. Conclusion and Future Work 



Since Facebook bought WhatsApp, instant messanging apps with security guarantees became 
more and more popular. The most prominent mobile applications for secure IM are Threema 
[46], Surespot [47], and TextSecure. In this paper, we have provided a detailed security 
analysis of TextSecure. First, we precisely described the protocol and then performed a security 
analysis of the individual steps of the protocol. This led to the discovery of several weaknesses, 
most notably an UKS attack. We proposed a mitigation and proved that, if our mitigation is 
applied, that TextSecure actually provides stateful authenticated encryption. To the best of our 
knowledge, this is the first formal verification of the security guarantees offered by the tool. 

While TextSecure’s implementation is open source, little is known about the competing 
messaging applications. While Threema makes use of the open source libary NaCl [49] for 
cryptographic operations, its protocol is kept confidential. Surespot is an open source project 
with its own cryptographic protocol. A protocol analysis for SURESPOT is (as far as we know) 
not done yet. A comparison of TextSecure and Surespot will be an interesting project for 
future work. 
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